為什麼要打造 SaaS 產品？從接案混沌走向系統化

四年接案路上的技術債務
在過去四年的接案經驗中，我打造了許多不同語言和框架組合的產品：

• 後端：Python/FastAPI、Kotlin/Spring Boot、Go/Gin、Node.js/Express
• 前端：React、Vue、打包和狀態管理
• 資料庫：MySQL、PostgreSQL、MongoDB 混用
• 部署：從傳統 VPS 到 Docker，散布在各種雲服務商

雖然能快速交付專案滿足客戶需求，但長期下來發現了嚴重問題：

• 維護困難：每個專案的技術棧都不同，需要在多種語言和框架間切換
• 技術債累積：版本升級常常破版，修復一個 bug 可能影響其他功能
• 重複造輪：相似的功能在不同專案中重複開發，無法有效複用
• 部署混亂：部署流程手動化，監控分散，難以統一管理
• 擴容困難：每當客戶需求增長，都需要重新評估架構和基礎設施

SaaS 產品願景：系統化解決方案
因此決定打造一個可「長期維運、快速擴容、方便拓展客戶」的工作室 SaaS 產品（Kyo-System），徹底改變接案模式：

技術選型一致：

• 全端 TypeScript：單一語言降低心智負擔，前後端型別共享
• ORPC 型別安全：內部實現型別安全的前後端呼叫，告別 API 文檔不同步
• 微服務架構：從 Kyo-OTP 開始，逐步擴展成完整的業務模組群
• 雲原生部署：從 Vultr 轉向 AWS 託管服務，強化穩定性與可觀測性

為什麼選 AWS（對應服務與理由）

• RDS for PostgreSQL：自動備份、Multi-AZ、高可用與維護版本策略，免自管資料庫巡檢。
• ElastiCache Redis：速率限制、OTP 短期存活、事件流；節點故障自動處理。
• ECS Fargate：無伺服器容器，無需維護節點；搭配 ALB 可滾動/藍綠部署。
• S3 + CloudFront：前端靜態快取；成本可控。
• Secrets Manager / Parameter Store：憑證與設定集中管理、審計可追蹤。
• CloudWatch + CodePipeline：集中式日誌與告警；配合 CI/CD 交付。

本系列的部署目標

• 30 天把 Kyo-OTP（第一個微服務）部署到生產級 AWS 架構，並建立後續模組可複用的 IaC 與 Runbook。
• 建立 SLO與告警流程，讓品質可量化。